This invention relates to computer networks and, more particularly, to management of resources and of Qualify of Service (QoS) in such computer networks.
Policy-Based Management (PBM) systems are software applications that are used to manage computer networks. Such management systems allow the network administrator to specify declarative rules, collectively called xe2x80x9cpoliciesxe2x80x9d or xe2x80x9cpolicy rulesxe2x80x9d of the form xe2x80x9cif event/condition then actionxe2x80x9d via a graphical or a textual interface. The PBM software translates these rules into low-level configuration commands, and sends them to the specified devices in the network. In other words, policy rules are used for remote, automatic configuration of network devices to drive the behavior of the network. The network performance, in turn, determines the quality of service (QoS) that a user observes. There are two key limitations of such prior policy-based management systems.
First, prior known policy-based management arrangements do not clearly distinguish the goal (i.e. the xe2x80x9cWhatxe2x80x9d) of management from the policy (i.e. the xe2x80x9cHowxe2x80x9d) that achieves the goal. Indeed, from a system administrator""s viewpoint, policy rules represent a specification of xe2x80x9cwhatxe2x80x9d needs to be achieved in terms of the network behavior. However, from the viewpoint of a client, i.e. the end user of a network service, such as Web or Domain Name Service (DNS), these rules do not represent his/her goals. The client is simply interested in realizing a certain level of service-level QoS. Indeed, the policy rules represent a xe2x80x9clow-levelxe2x80x9d specification of xe2x80x9chowxe2x80x9d the client""s QoS goals may be achieved, but not the goals themselves. In other words, there is no support in prior known policy-based management arrangements for specifying the client""s service-level QoS goals along with the network management policy definition.
The second limitation of prior known policy-based management systems is that they are provided to the administrator as monolithic systems. That is, the functionality of known systems cannot easily be modified, or extended, by the administrator in an incremental manner. We illustrate this limitation with an example. As indicated above, the key task of policy-based management systems is to remotely send configuration commands to network devices. The particular protocol (SNMP, HTTP, LDAP, CLI over Telnet, or the like) used to send the commands depends on the network device, and as such, a policy-based management system supports a limited set of network devices and protocols. If a computer network deploys a currently unsupported device, then the lo system administrator must either live with the limitation, or wait for the vendor to supply an upgrade of the whole PBM software system, which supports this device. This second limitation is highlighted further by introduction of new protocols and new devices in the market. Moreover, even if a vendor continually upgrades the PBM software to support new protocols and devices, the system remains non-operational during the upgrade. In summary, no prior known policy-based management system allows for online modification of its xe2x80x9csub-systemsxe2x80x9d, nor does it allow extensibility (in terms of device and protocol support) by a system administrator.
Problems and/or limitations of prior policy-based network management arrangements are addressed by employing a xe2x80x9cpolicy component-basedxe2x80x9d system architecture instead of a monolithic one. This policy component-based architecture allows policies to be defined via run-time loading of xe2x80x9cpolicy packagesxe2x80x9d that are collections of reusable xe2x80x9cpolicy componentsxe2x80x9d. Such reusable policy components may be written by the vendor of the policy-based management system, or by system administrators, who are the users of policy-based management systems or even by third-party people, who may be experts in the management of specific application domains such as vendors of network devices. In the latter case, these policy components can be assembled into a functionally complete policy package by system administrators. Alternatively, the system administrators can also load a pre-assembled policy package into a management server and only have to specify the desired service level goals.
Specifically, one embodiment of the invention employs a management server including a graphical interface that allows a system administrator to load pre-assembled policy packages into the management server. Further, it allows the administrator to activate one or more policy packages, which requires supplying prescribed parameter values for a QoS goal and a policy enforcement xe2x80x9cdomainxe2x80x9d. A policy package includes all the logic needed to enforce a particular type of service-level QoS goal. Once activated, a policy package ensures that the specified QoS goal is delivered by monitoring and controlling network elements specified in the enforcement xe2x80x9cdomainxe2x80x9d. As indicated above, the logic in the policy components of a policy package represents the xe2x80x9chowxe2x80x9d of management, whereas the specified goal parameter represents the xe2x80x9cwhatxe2x80x9d of management. An advantage of this embodiment of the invention is that it encapsulates both the xe2x80x9cWhatxe2x80x9d and xe2x80x9cHowxe2x80x9d of management in the same framework.
In another embodiment of the invention, service-level QoS goals are stored in a goal repository and continuously updated by adding, redefining, or removing service-level QoS goals as requested by an administrator.
In still another embodiment of the invention, policy packages are stored in a package repository where they are added, removed or updated by the system administrator.